Internet Engineering Task Force (IETF) M. Mohali 
Request for Comments: 8498 Orange 
Updates: 5502 February 2019 
Category: Informational 

ISSN: 2070-1721 


A P-Served-User Header Field Parameter for an 
Originating Call Diversion (CDIV) Session Case in the 
Session Initiation Protocol (SIP) 


Abstract 


The P-Served-User header field was defined based on a requirement 
from the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia 
Subsystem) in order to convey the identity of the served user, his/ 
her registration state, and the session case that applies to that 
particular communication session and application invocation. A 
session case is metadata that captures the status of the session of a 
served user regardless of whether or not the served user is 
registered or the session originates or terminates with the served 
user. This document updates RFC 5502 by defining a new P-Served-User 
header field parameter, "orig-cdiv". The parameter conveys the 
session case used by a proxy when handling an originating session 
after Call Diversion (CDIV) services have been invoked for the served 
user. This document also fixes the ABNF in RFC 5502 and provides 
more guidance for using the P-Served-User header field in IP 
networks. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are candidates for any level of Internet 
Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8498. 
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1. Introduction 
1.1. General 


The P-Served-User header field [RFC5502] was defined based on a 
requirement from the 3rd Generation Partnership Project (3GPP) IMS 
(IP Multimedia Subsystem) in order to convey the identity of the 
served user, his/her registration state, and the session case between 
a Serving Call Session Control Function (S-CSCF) and an Application 
Server (AS) on the IMS Service Control (ISC) interface. A session 
case is metadata that captures the status of the session of a served 
user regardless of whether or not the served user is registered or 
the session originates or terminates with the served user. For more 
information on session cases and the IMS, a detailed description can 
be found in [TS.3GPP.24.229]. 


[RFC5502] defines the originating and terminating session cases for a 
registered or unregistered user. This document extends the P-Served- 
User header field to include the session case for a forwarded leg 
when both a CDIV service has been invoked and an originating service 
of the diverting user has to be triggered. 
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1 


aes 


The sessioncase-param parameter of the P-Served-User header field is 
extended with the "orig-cdiv" parameter for this originating-after- 
CDIV session case. 


The following section defines usage of the "orig-cdiv" parameter of 
the P-Served-User header field, Section 3 discusses the applicability 
and scope of this new header field parameter, and Section 4 specifies 
the proxy behavior for handling the new header field parameter. 
Section 5 clarifies some of the [RFC5502] procedures, Section 6 
describes th xtended syntax and corrects the syntax of [RFC5502], 
Section 7 gives some call flow examples, Section 8 registers the 
P-Served-User header field parameters with IANA, and Section 9 
discusses the security properties of the environment where this new 
header field parameter is intended to be used. 


Basic Use Case 


In the 3GPP IMS (IP Multimedia Subsystem), the S-CSCF (Serving CSCF) 
is a SIP proxy that serves as a registrar and handles originating and 
terminating session states for users assigned to it. This means that 
any call that is originated by a specific user or any call that is 
terminated to that specific user will pass through the S-CSCF that is 
assigned to that user. 


At the moment that an S-CSCF is assigned to a specific user, the user 
profile is downloaded from the Home Subscriber Server (HSS) to that 
S-CSCF; see [TS.3GPP.29.228]. The user profile contains the list of 
actions to be taken by the S-CSCF for the served user depending on 
the session direction (originating or terminating) and the user state 
(registered or not) in the IMS network. With this user profile, the 
S-CSCF determines the current case and applies the corresponding 
actions such as forwarding the request to an AS. The AS then goes 
through a similar process of determining who is the current served 
user, what is his/her "registration state", and what is the "session 
case" of the session. [RFC5502] defines all those parameters and in 
particular the originating and terminating session cases. 


In basic call scenarios, there is no particular issue for the S-CSCF 
and AS to know which scenario needs to be realized, but in case of 
CDIV services for which the session is re-targeted, the session cases 
defined in [RFC5502] pose some limitations as described in the 
following section. 


Mohali Informational [Page 4] 


RFC 8498 P-Served-User Parameter for CDIV in SIP February 2019 


1.3. Problem Statement 


To illustrate the problem statement, let’s imagine Alice trying to 
call Bob and Bob having a CDIV service activated towards Carol’s 
address. In the case of a CDIV service, the received request is 
first treated as a terminating session case (at Bob’s side), and the 
terminating filter criteria configured in the S-CSCF is performed. A 
filter criteria is information in the user profile that determines 
whether an initial request is sent to a particular AS. When the AS 
receives the call initiation request, the AS is able to determine th 
served user (Bob) and the session case (here "term") from the 
received P-Served-User header field content and is able to execute 
terminating services. When the CDIV service is executed (as a 
terminating service of Bob), the AS changes the target (Request-—URI) 
of the session (toward Carol’s address) and a new call leg is 
created. The served user becomes the diverting user. This new call 
leg could be considered as an originating call leg from the diverting 
user (Bob), but this is not the case. Indeed, the originating user 
remains the same (Alice), and some of the diverting user’s 
originating services should not be triggered as if it was an 
originating call. For instance, the originating user identity 
(Alice) should not be restricted because the diverting user (Bob) has 
a privacy service for his own identity. The privacy of the diverting 
user should apply to information related to this user only (e.g., in 
the History-Info header field). In the same manner, some specific 
services will need to be triggered on the outgoing leg after a CDIV. 
Without a dedicated session case for originating-after-CDIV, the 
S-CSCF cannot trigger an originating service for the diverting user, 
nor can an AS execute the procedures for this particular session 
case. 


For this use case, this document creates a new parameter 
("orig-cdiv") for the originating-after-CDIV session case to be 
embedded in the P-Served-User header field. 


2. Conventions and Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 


"OPTIONAL" in this document are to be interpreted as described in BCP 
14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 
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3. 


Applicability 


The use of the P-Served-User header field extensions is only 
applicable inside a Trust Domain [RFC3324] for the P-Served-User 
header field. Nodes in such a Trust Domain explicitly trust each 
other to convey the served user and to be responsible for withholding 
that information outside of the Trust Domain. The means by which the 
network determines the served user and the policies that are executed 
for a specific served user is outside the scope of this document. 


Proxy Behavior and Parameter Handling 


The following section illustrates how this header field parameter can 
be used in a 3GPP network. 


For a terminating call, the following steps will be followed: 
1. The S-CSCF receives the initial INVITE request for a terminating 
call and determines that the session case is for a terminating 


user as described in [RFC5502]. 


2. The S-CSCF determines who is the served user by looking at the 
Request-URI and saves the current Request-URI. 


3. The S-CSCF analyzes the filter criteria. It then sends the 
request to the AS of the served user as an INVITE that includes 
the P-Served-User header field with the "sescase" parameter set 
to "term" and the "regstate" set to the corresponding value in 
order to trigger execution of terminating services. 


4. Based on some criteria, the AS concludes that the request has to 
be diverted to another target user or application. The AS 
replaces the received Request-URI with the new diverted-to 
address and stores the successive Request-URI (s) values by adding 
one or two History-Info header field entry(ies) [RFC7044] in the 
outgoing INVITE. In the History-Info header field, the served 
user address is tagged by using the mp-param header field 
parameter added in the newly created entry that contains the 
diverted-to address. The AS forwards the INVITE request back to 
the S-CSCF. 


5. When receiving back the INVITE request, the S-CSCF can see that 
the topmost Route header field contains its own hostname, but the 
Request-URI does not match the saved Request-URI. In this case, 
the S-CSCF updates the P-Served-User header field content by 
replacing the "sescase" parameter with the "orig-cdiv" parameter. 
The P-Served-User header field value remains unchanged. 
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The S-CSCF forwards the INVITE request to an AS that hosts the 
served user’s (diverting user’s) originating services, which need 
to be executed on the forwarded leg after a CDIV service. 


When the AS receives the INVITE request, it determines that the 
session case is for the "orig-cdiv" session case and performs the 
originating services to be executed after retargeting for the 
diverting user (i.e., served user). 


Clarification of RFC 5502 Procedures 


his document provides the following guidance for the handling of the 
-Served-User header field that is missing in [RFC5502]: 


The P-Served-User header field MUST NOT be repeated within a 
request for a particular session at a particular time for the 
reason that session cases are mutually exclusive. This document 
updates [RFC5502] to clearly state that the P-Served-User header 
field MUST NOT contain multiple values either comma-separated or 
header-separated. This document also updates the syntax of the 
header from [RFC5502] to reflect this uniqueness of parameter 
values. 


[RFC5502] does not clearly state what to do with the received 
P-Served-User header field when a call is diverted to another 
destination. This document highlights that there are several ways 
of handling the P-Served-User header field: the S-CSCF could store 
the previous "regstate" value and decide that the same value 
applies, the "regstate" may no longer be relevant after a 
diverting service so the S-CSCF removes it, or the "regstate" 
could be combined with the "orig-cdiv" session case to provide 
different services depending on whether the served user is 
registered or unregistered. These choices are implementation 
dependent. 


Syntax 


General 


RFC5502] defines the P-Served-User header field with the 


essioncase-param parameter "sescase", which is specified as having 
orig" and "term" as predefined values. This document defines an 
dditional parameter, "orig-cdiv", for the sessioncase-param. 


ecause this document extends the existing sessioncase-param 
arameter, and because errors have been identified in the syntax, 
his document corrects and extends the P-Served-User header field. 
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The extension of the sessioncase-param parameter to add the 
"orig-cdiv" session case is done in a way that fits the parameter 
format introduced in Release 11 of the 3GPP [TS.3GPP.24.229] and 
maintains backward compatibility. 


"EQUAL", “HCOLON", "SEMI", "name-addr", "“addr-spec", and 
"generic-param" are defined in [RFC3261]. 


If the "addr-spec" contains a comma, question mark, or semicolon, the 
"name-addr" form MUST be used. The "name-addr" form requires the us 
of angle brackets (< and >). 


6.2. ABNF 


The Augmented Backus-Naur Form (ABNF) [RFC5234] syntax of the 
P-Served-User header field is described in [RFC5502]. 


This document updates [RFC5502] to correct the P-Served-User header 
field ABNF syntax and extend it as the following: 


P-Served-User = "P-Served-User" HCOLON PServedUser-value 
* (SEMI served-user-param) 
served-user-param = sessioncase-param 


/ registration-state-param 

/ generic-param 
PServedUser-value = name-addr / addr-spec 
sessioncase-param "sescase" EQUAL ("orig"/"term")/ orig-cdiv 
registration-state-param "regstate" EQUAL ("unreg" / "reg") 
orig-cdiv = “orig-cdiv" 


Examples of possible P-Served-User header fields: 


P-Served-User: <sip:user@example.com>; orig-cdiv; regstate=reg 
or 
P-Served-User: <sip:user@example.com>; orig-cdiv 
or 
P-Served-User: <sip:user@example.com>; sescase=term; regstate=unreg 


This document allows choosing between "addr-spec" and "name-addr" 
when constructing the header field value. As specified in RFC 8217, 
the "addr-spec" form MUST NOT be used if its value would contain a 
comma, semicolon, or question mark [RFC8217]. 
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7. Call Flow Examples 


7.1. Call Diversion Case 
The following call flow shows a session establishment when Alice 
calls Bob, who has a CDIV service that diverts to Carol when Bob is 
busy. 
proxy server UA 
Alice Bob" Serr S=CSCP=Bit ns eis she's a E E ETS Bob 
INVITE F1 | 
--------------- > INVITE F2 | 
--------------—-— >| 
INVITE F3 | 
<--------------- | INVITE F4 
pe ge na Sa ea ye ee Sa a E SS So gp > 
486 F5 
< Sei ct et ans lee ol eal a oi da A to ia lca 
486 F6 
a at gph eee Tea! Sa eet pt > 
INVITE F7 
< Se ee ee 
INVITE F8 
oe ee ee ee > 
INVITE F9 
KAS SSS eesSSoSse INVITE F10 
180 F11 
180 F12 <--------------- 
180 F13 KSSSSSeSSe-SSS— 
180 F14 Lec se ee a ee Se 
< a cn pms et lt a pata Se ga 
[Alice calls Bob] 


F1 INVITE Alice -> S-CSCF-B 

INVITE sip:bob@example.com SIP/2.0 
From: Alice <sip:alice@domaina.com>; tag=1928301774 
To: Bob <sip:bob@example.com> 


F2 INVITE S-CSCF-B -> AS-B 
INVITE sip:bob@example.com SIP/2.0 
From: Alice <sip:alice@domaina.com>; tag=1928301774 
To: Bob <sip:bob@example.com> 
P-Served-User: <sip:bob@example.com>; term; regstate=reg 
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F3 INVITE AS-B -> S-CSCF-B 
INVITE sip:bob@example.com SIP/2.0 
From: Alice <sip:alice@domaina.com>; tag=1928301774 
To: Bob <sip:bob@example.com> 
P-Served-User: <sip:bob@example.com>; term; regstate=reg 


F4 INVITE S-CSCF-B -> Bob 
INVITE sip:bob@192.0.2.4 SIP/2.0 
From: Alice <sip:alice@domaina.com>; tag=1928301774 
To: Bob <sip:bob@example.com> 
P-Served-User: <sip:bob@example.com>; term; regstate=reg 


[Bob is busy. His CDIV when busy is invoked towards Carol] 


F5-F6 486 BUSY Bob -> S-CSCF-B -> AS-B 

486 BUSY 

From: Alice <sip:alice@domaina.com>; tag=1928301774 
To: Bob <sip:bob@example.com>;tag=es43sd 


[Alice’s call is diverted to Carol] 


F7 INVITE AS-B -> S-CSCF-B 
INVITE sip:carol@domainc.com SIP/2.0 
From: Alice <sip:alice@domaina.com>; tag=1928301774 
To: Bob <sip:bob@example.com> 
P-Served-User: <sip:bob@example.com>; term; regstate=reg 


[The forwarded leg to Carol is identified as an originating call after 
CDIV, which should not trigger all of Bob’s originating services] 


F8 INVITE S-CSCF-B -> AS-B 
INVITE sip:carol@domainc.com SIP/2.0 
From: Alice <sip:alice@domaina.com>; tag=1928301774 
To: Bob <sip:bob@example.com> 
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg 


F9 INVITE AS-B -> S-CSCF-B 
INVITE sip:carol@domainc.com SIP/2.0 
From: Alice <sip:alice@domaina.com>; tag=1928301774 
To: Bob <sip:bob@example.com> 
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg 


F10 INVITE S-CSCF-B -> Carol 
INVITE sip:carol@192.0.2.7 SIP/2.0 
From: Alice <sip:alice@domaina.com>;tag=1928301774 
To: Bob <sip:bob@example.com> 


Figure 1. P-Served-User During CDIV Service 
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ow shows a CDIV use case for which Alice has no 
service and Bob has an unconditional CDIV 
and an identity presentation restriction 


Carol 


state=reg 


service. 
proxy server UA 
Alice Bobs). 3.:S=CSCP=B a. fica hve ASS Brene ead Daten Bob 
INVITE F1 
oe gt ee le eg > INVITE F2 
Se ee ee > 
INVITE F3 
< = SS Se ee 
INVITE F4 
Se ae ee Pa Ne fey Se ee TN > 
INVITE F5 
SS aS INVITE F6 
Rh a a ar a pak a i E a a A a a te a a en le > 
180 F8 < 
180 Bo A 
180 F10 <--------------- 
< ae a a og ee rs 
[Alice calls Bob] 
F1 INVITE Alice -> S-CSCF-B 
INVITE sip:bob@example.com SIP/2.0 
From: Alice <sip:alice@domaina.com>; tag=1928301774 
To: Bob <sip:bob@example.com> 
Supported: histinfo 
F2 INVITE S-CSCF-B -> AS-B 
INVITE sip:bob@example.com SIP/2.0 
From: Alice <sip:alice@domaina.com>; tag=1928301774 
To: Bob <sip:bob@example.com> 
P-Served-User: <sip:bob@example.com>; term; reg 
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[Bob’s unconditional CDIV to Carol is triggered] 


F3 INVITE AS-B -> S-CSCF-B 
INVITE sip:carol@domainc.com SIP/2.0 
From: Alice <sip:alice@domaina.com>; tag=1928301774 
To: Carol <sip:carol@domainc.com> 
P-Served-User: <sip:bob@example.com>; term; regstate=reg 
History-Info: 
<sip:bob@example.com>; index=1, 
<sip:carol@domainc.com; cause=302>; index=1.1;mp=1 


[Alice’s call is diverted to Carol] 


F4 INVITE S-CSCF-B -> AS-B 
INVITE sip:carol@domainc.com SIP/2.0 
From: Alice <sip:alice@domaina.com>; tag=1928301774 
To: Carol <sip:carol@domainc.com> 
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg 
History-Info: 
<sip:bob@example.com>; index=1, 
<sip:carol@domainc.com; cause=302>; index=1.1;mp=1 


F5 INVITE AS-B -> S-CSCF-B 
INVITE sip:carol@domainc.com SIP/2.0 
From: Alice <sip:alice@domaina.com>; tag=1928301774 
To: Carol <sip:carol@domainc.com> 
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg 
History-Info: 
<sip:bob@example.com?privacy=history>; index=1, 
<sip:carol@domainc.com; cause=302>; index=1.1;mp=1 


[Forwarded leg to Carol is identified as an originating call after 
CDIV that allows Bob’s privacy service to be applied to his 
identity within the History-Info header field] 


F6 INVITE S-CSCF-B -> Carol 
INVITE sip:carol@192.0.2.7 SIP/2.0 
From: Alice <sip:alice@domaina.com>; tag=1928301774 
To: Carol <sip:carol@domainc.com> 
History-Info: 
<sip:bob@example.com?privacy=history>; index=1, 
<sip:carol@domainc.com; cause=302>; index=1.1;mp=1 
<sip:carol@192.0.2.7>; index=1.1.1;rc=1.1 


Figure 2. P-Served-User When Privacy Requested 
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8. 


IANA Considerations 


The syntax of the P-Served-User header field [RFC5502] is updated in 
Section 4 of this document. 


IANA has updated the existing row for the P-Served-User header field 
in the "Header Fields" subregistry within the "Session Initiation 
Protocol (SIP) Parameters" registry: 


Header Name Compact Form Reference 


P-Served-User none [RFC5502] [RFC8498] 


IANA has added new rows for the P-Served-User header field parameters 
in the "Header Field Parameters and Parameter Values" subregistry 
within the "Session Initiation Protocol (SIP) Parameters" registry 
(as per the registry created by [RFC3968]): 


Header Field Parameter Name Predefined Values Reference 
P-Served-User sescase Yes [RFC5502] 
P-Served-User regstate Yes [RFC5502] 
P-Served-User orig-cdiv No [RFC8498] 


Security Considerations 
The security considerations in [RFC5502] apply. 


As the "orig-cdiv" parameter of the P-Served-User header field can be 
used to trigger applications when a call is diverted, it is important 
to ensure that the parameter has not been added to the SIP message by 
an unauthorized SIP entity. Thus, the P-Served-User header field is 
to be used in a trusted environment, and proxies MUST NOT insert the 
header unless they have sufficient knowledge that the route set 
includes another trusted proxy. 


Mohali Informational [Page 13] 


RFC 8498 


P-Served-User Parameter for CDIV in SIP February 2019 


10. References 


10.1. Normative References 


[RFC2119] 


[RFC3324] 


[RFC3261] 


[RFC8174] 


[RFC8217] 


[RFC3968] 


[RFC5234] 


[RFC7044] 


Mohali 


Bradner, S., "Key words for use in RFCs to Indicate 
Requirement Levels", BCP 14, RFC 2119, 

DOI 10.17487/RFC2119, March 1997, 
<https://www.rfc-editor.org/info/rfc2119>. 


Watson, M., "Short Term Requirements for Network Asserted 
Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, 
<https://www.rfc-editor.org/info/rfc3324>. 


Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 
A., Peterson, J., Sparks, R., Handley, M., and 

E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, 
DOI 10.17487/RFC3261, June 2002, 
<https://www.rfc-editor.org/info/rfc3261>. 


Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 
May 2017, <https://www.rfc-editor.org/info/rfc8174>. 


Sparks, R., “Clarifications for When to Use the name-addr 
Production in SIP Messages", RFC 8217, 

DOI 10.17487/RFC8217, August 2017, 
<https://www.rfc-editor.org/info/rfc8217>. 


Camarillo, G., "The Internet Assigned Number Authority 
(IANA) Header Field Parameter Registry for the Session 
Initiation Protocol (SIP)", BCP 98, RFC 3968, 

DOI 10.17487/RFC3968, December 2004, 
<https://www.rfc-editor.org/info/rfc3968>. 


Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 
Specifications: ABNF", STD 68, RFC 5234, 

DOI 10.17487/RFC5234, January 2008, 
<https://www.rfc-editor.org/info/rfc5234>. 


Barnes, M., Audet, F., Schubert, S., van Elburg, J., and 
C. Holmberg, "An Extension to the Session Initiation 
Protocol (SIP) for Request History Information", RFC 7044, 
DOI 10.17487/RFC7044, February 2014, 
<https://www.rfc-editor.org/info/rfc7044>. 


Informational [Page 14] 


RFC 8498 P-Served-User Parameter for CDIV in SIP February 2019 


[RFC5502] van Elburg, J., "The SIP P-Served-User Private-Header 
(P-Header) for the 3GPP IP Multimedia (IM) Core Network 
(CN) Subsystem", RFC 5502, DOI 10.17487/RFC5502, April 
2009, <https://www.rfc-editor.org/info/rfc5502>. 


10.2. Informative References 


[TS.3GPP.24.229] 
3GPP, "IP multimedia call control protocol based on 
Session Initiation Protocol (SIP) and Session Description 
Protocol (SDP);Stage 3", 3GPP TS 24.229 11.28.0, December 
2018. 


[TS.3GPP.29.228] 
3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; 
Signalling flows and message contents", 3GPP TS 29.228 
15.1.0, September 2018. 


Acknowledgments 


The author wishes to thank the 3GPP community for providing guidance, 
input, and comments on the document. Thanks to Dale Worley, Jean 
Mahoney, and Ben Campbell for their careful review of the document. 
Thanks to Paul Kyzivat and Adam Roach. A special thanks to Christer 
Holmberg. 


Author’s Address 
Marianne Mohali 
Orange 
Orange Gardens, 44 avenue de la Republique 
Chatillon 92326 


France 


Email: marianne.mohali@orange.com 


Mohali Informational [Page 15] 


